The MGC and the MG are two key components in a packet-switched network. The MGC is responsible for call control and the MG is responsible for service bearing, thus separating the call control plane from the service bearer plane, sharing network resources sufficiently, simplifying the equipment upgrade and service extension, and reducing the costs of development and maintenance drastically. The networking of an MGC and two MGs in a Next Generation Network (NGN) is as shown in FIG. 1.
The gateway control protocol (or media gateway control protocol) is a primary protocol for communications between the MG and the MGC. The currently prevalent gateway control protocols include the H.248/MeGaCo and the MGCP. The Media Gateway Control Protocol (MGCP) version 1 was developed by the Internet Engineering Task Force (IETF) in October 1999 and revised in January 2003. The H.248/MeGaCo version 1 was developed by the IETF and the International Telecommunications Union (ITU) in November 2000 and revised in June 2003. The H.248 version 2 was developed by the ITU in May 2002 and revised in March 2004. The H.248 version 3 was developed by the ITU in September 2005.
Taking the H.248 protocol as an example, various resources on the MG are expressed as terminations abstractly. Terminations are categorized into physical terminations and ephemeral terminations. Physical terminations are physical entities characterized by semi-permanent existence, for example, Time Division Multiplex (TDM) channels. Ephemeral terminations are public resources requested for being used temporarily and released after use, for example, Real-time Transport Protocol (RTP) streams. A root termination represents the entirety of the MG. The associations between terminations are abstractly represented by contexts. A context may include multiple terminations. Thus, a topology is used to describe the relationship between the terminations. Terminations that are not associated with other terminations are included in a null context.
Based on the abstract model of the protocol, call continuity is actually an operation on the termination and the context. Such operations are performed through command requests and replies between the MGC and the MG. Command types include: Add, Modify, Subtract, Move, AuditValue, AuditCapabilities, Notify, and ServiceChange. Command parameters, also known as descriptors, are categorized into property, signal, event, and statistic. Parameters with service relevancy are aggregated into a package logically.
As specified in H.248, an event refers to an occasion that needs to be monitored by the MG, for example, off-hook, on-hook, dialing, hooking, or network fault, quality alarm, and timer expiry. The occurrence of an event triggers the MG to notify the MGC and/or take certain actions. Generally, an event is delivered by the MGC to the MG, or preset on the MG, and is identified by “PackageID/EventID” which carries a RequestID and other necessary parameters. The delivered event is also called a requested event. Afterward, once the MG detects occurrence of the event, the MG reports the event to the MGC. The event is also identified by “PackageID/EventID” which carries the RequestID and other necessary parameters. The reported event is also called an observed event. The requested event and the observed event are correlated with the same request ID. The parameters carried in the requested event are independent of the parameters carried in the observed event. The event subsequently delivered for a certain termination replaces the previously delivered event.
When the MGC instructs the MG to add the termination to a context to create a media stream, the MGC generally describes the features of the termination through media descriptors. Media descriptors include: TerminationState descriptors, and Stream descriptors. The TerminationState descriptors describe the stream-unrelated features of the termination, including the parameters such as ServiceState and EventBufferControl. The Stream descriptors describe the stream-related features of the termination, including: LocalControl descriptors, Local descriptors, and Remote descriptors. The LocalControl descriptors include the parameters such as Mode, ReserveGroup, and ReserveValue. The Local descriptors describe the parameters for the local end to receive a media stream (namely, sent by the remote end). The Remote descriptors describe the parameters for the remote end to receive a media stream (namely, sent by the local end), for example, IP address or port number, codec algorithm, and packet time, which are organized through a Session Description Protocol (SDP).
Through the Local descriptors and the Remote descriptors, the MGC reserves and grants resources to the MG for coding and decoding the data streams and the media of the termination. Through such descriptors, the MG returns a response that carries the actually reserved resources. After receiving a Local descriptor or Remote descriptor, the MG performs operations which depend on the property values of the two reservation property parameters ReserveValue and ReserveGroup in the LocalControl descriptors. If the reservation property values are “False”, only one resource may be reserved; if the reservation property values are “True”, all resources may be reserved.
Currently, two models for providing Quality of Service (QoS) exist on the Internet: integrated service (IntServ) model, and differentiated service (DiffServ) model. The IntServ model is designed to provide end-to-end QoS. The endpoint requests a certain QoS level for its data streams. If the network accepts the request, the router processes the data streams according to this QoS level. The DiffServ model uses a Resource ReserVation Protocol (RSVP) to provide two types of services: guaranteed service, and controlled-load service. The guaranteed service meets the QoS requirements of applications by providing guaranteed bandwidths and delay restrictions, for example, reserving a 10M bandwidth and an end-to-end transmission delay not greater than 1 s for the traffic of the VoIP application. The controlled-load service ensures provision of a normal QoS level for the packets in the case of network overload in a way similar to best-effort, namely, meets the low-delay and low-packet-loss-ratio requirements of certain service packets in the case of network congestion.
RSVP is a network control protocol that provides a path resource reservation mechanism. The bearer path set up in the IP network through RSVP provides guaranteed bandwidths and router resources for the corresponding data streams.
The operating principles of RSVP are as follows: The sender sends a resource request message to the destination address through RSVP, and each router that supports RSVP sets up a path state table along the downlink route; to obtain resource reservation, the receiver sends an uplink RESV message, indicating the required QoS service type and notifying the resources (such as the transport protocol and port number) reserved for the packet; when each router that supports RSVP receives the RESV message along the uplink path, the router uses an admission control process to authenticate the request and configures the required resources. If rejecting the request, the router returns an error message to the receiver; if accepting the request, the router sends an uplink RESV message to the next router; when the last router receives the RESV message and accepts the request, the last router sends an acknowledgment message to the receiver. The foregoing process actually sets up a bearer path from the sender to the receiver, and the routers on the path reserve resources for the data likely to arrive.
Currently, H.248 implements single-point reservation of resources, namely, reserves resources for a stream on the termination only on the MG. When the MG receives a resource request message on the bearer path, for example, an RSVP Path message sent by the data sender, because H.248 does not support the mechanism of setting up a bearer path (such as an RSVP path) in the case that the MG and the MGC serve as data receivers, the MG and the MGC are unable to respond to the request message or complete the setup of the bearer path. Therefore, no support is provided for implementing the session between users in the case that the MG or the MGC needs to serve as data receivers.